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Sir: 

In accordance with 37 CFR 41 .41 , the Appellant submits this Reply Brief in 
response to the Examiner's Answer mailed on June 22, 2010 ("Examiner's Answer"), 
with a reply period through August 23, 2010. Claims 1-31 are pending in the present 
Application. The Appellant has responded to the Examiner in the Examiner's 
Answer, as found in the following Arguments section. 
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As may be verified in the Final Office Action (pages 2-18), dated August 13, 
2009 ("Final Office Action"), claims 29-31 are rejected under 35 USC 101 for 
allegedly being directed to non-statutory subject matter. Claims 1-4, 15-20 and 23 
are rejected under 35 USC 102(e) as anticipated by USP 6,226,680 ("Boucher"). 
Claims 10 and 11 are rejected under 35 USC 103(a) as being unpatentable over 
Boucher, as applied to claim 1 above, and further in view of USPP 2002/0198934 
("Kistler"). Claims 12-14 are rejected under 35 USC 103(a) as being unpatentable 
over Boucher, as applied to claim 1 above, and further in view of Microsoft 
Winsock Direct and Protocol Offload on SANs, 03/03/2001 ("Microsoft"). Claim 21 
is rejected under 35 USC 103(a) as being unpatentable over Boucher, as applied 
to claim 18 above, and further in view of Official Notice ("ON"). Claim 22 is 
rejected under 35 USC 103(a) as being unpatentable over Boucher, as applied to 
claim 18 above, and further in view of USPP 2002/0041566 ("Yang"). Claims 5-8 
and 24-28 are rejected under 35 USC 103(a) as being unpatentable over Boucher, 
as applied to claim 1 above, and further in view of USPP 2003/0046330 ("Hayes"). 
Claim 29-31 are rejected under 35 USC 103(a) as being unpatentable over 
Boucher, and further in view of Callaghan (NFS over RDMA) ("Callaghan"). 

To aid the Board in identifying corresponding arguments, the Appellant has 
used the same headings in the Argument section of this Reply Brief as the 
headings found in the Appellant's corresponding Brief on Appeal. The Brief on 
Appeal has a date of deposit of February 1 9, 201 0. 
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STATUS OF THE CLAIMS 

Claims 1-31 were finally rejected. Pending claims 1-31 are the subject of 
this appeal. 
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ARGUMENTS 
Rejection to Claims 29-31 under 35 U.S.C. § 101 



The Examiner's Answer (page 18) states the following: 

"Claims 29-31 are rejected under 35 U.S.C. 101 the claimed 
invention is directed to non-statutory subject matter. A driver 
executable on a computer system is non-statutory subject matter, 
since a driver executable on a computer system is just computer 
program codes and does not comprise the computer system or any 
hardware elements in that computer system. Applicant argues in the 
brief that the unified driver executes the program codes in the 
computer system; therefore, the unified driver is tied to a computer 
system, and is statutory. The examiner respectfully disagrees. The 
claimed subject matter is the unified driver, which is executable by a 
computer and does not include the computer itself, and is software 
per se, or non-statutory subject matter." 

The Appellant stands by the arguments made in the corresponding section of the 
Brief on Appeal (see page 1 1 ). Namely, Applicant's claim 29 recites that the "unified 
driver executes the program codes in the computer system ". In this regard, the 
driver program code is tied to at least a computer system, which becomes part of the 
functions in performing the recited steps by the computer system. Therefore, the 
Appellant maintains that the recited unified driver is statutory subject matter and is 
patentable. The Appellant respectfully requests that the rejection to claim 29 under 35 
USC 101 be withdrawn. Likewise, claims 30-31 depend from claim 29, and are submitted 
to be also patentable. In regards to independent claims 1 and 1 1 , 
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ll-A. Independent Claims 1 and 18 

The Appellant stands by the arguments made in the corresponding section 
of the Brief on Appeal. Namely, Boucher does not disclose or suggest at least the 
limitation of "processor operable to process a plurality of different types of network 
traffic, wherein each of said plurality of different types of network traffic 
corresponds to a different network protocol ," as recited in the Appellant's claim 
1. 

In regards to independent claims 1 and 18, the Examiner's Answer (pages 

18-19) states the following: 

"Argument: appellant has argued that prior art Boucher does not 
teach "the processor operable to process a plurality of different types 
of network traffic, wherein each of said plurality of different types of 
network traffic corresponds to a different network protocol." 

Response: It is respectfully submitted that Boucher does teach the 
limitation. Based on the claimed language, any processor that can 
process two different traffics that each is a different protocol can read 
on the claims. Boucher clearly teaches a processor coupled to the 
network connector (fig. 13, microprocessor 470, col. 16 line 62-col. 
17 line 13), the processor being operable to process a plurality of 
different types of network traffic, wherein each of said plurality of 
different types of network traffic corresponds to a different network 
protocol (abstract, col. 3 lines 35-67, col. 6 lines 33-55, col. 13 lines 
24-35, the intelligent network interface card INIC's processor 
supports an fast path candidate traffics by identifying protocols 
such as TCP/IP or SPX/IPX and slow path traffics by identifying 
input packet protocol types, col. 14 lines 37-40, TCP, TTCP, SPX 
are fast path protocol traffic, col. 14, lines 51-53, traffic with non- 
accelerated protocols are processed conventionally using the 
slow path processing)." (emphasis added) 
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The Examiner seems to allege that packets with headers denoting the 

TCP/IP or SPX/IPX protocol are exclusively processed as fast path candidates 

only, and will never be processed by the slow path (i.e., as a conventional protocol 

stack). Contrary to the Examiner's allegation, Boucher discloses that the slow path 

(i.e., conventional protocol stack) is used by all the packets with message header 

denoting TCP/IP and SPX/IPX protocols, in setting up a fast path connection. 

More specifically, the Examiner is referred to the following citation of Boucher (see 

Boucher col. 14, II. 37-53): 

"...Conversely, in receiving a TCP, TTCP, SPX or similar message 
packet from the network 210 to be used in setting up a fast-path 
connection, miniport driver 306 diverts that message packet to 
command driver 300 for processing. The driver 300 processes 
the message packet to create a context for that message, with 
the driver 302 passing the context and command instructions back to 
the INIC 200 as a CCB for sending data of subsequent messages for 
the same connection along a fast-path. Hundreds of TCP, TTCP, 
SPX or similar CCB connections may be held indefinitely by the INIC, 
although a least recently used (LRU) algorithm is employed for the 
case when the INIC cache is full. The driver 300 can also create a 
connection context for a TTCP request which is passed to the 
INIC 200 as a CCB, allowing fast-path transmission of a TTCP 
reply to the request. A message having a protocol that is not 
accelerated can be processed conventionally by protocol stack 310." 

Boucher, in the above citation, clearly discloses that the same slow path 
(i.e., common protocol stack 300), receives and processes the TCP, TTCP, SPX 
message packets (i.e., the alleged "fast path candidates packets") with headers 
denoting TCP/IP or SPX/IPX (i.e., the alleged "fast path protocol"), for processing 
to create a connection context. Furthermore, as pointed out by the Appellant in the 
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Brief on Appeal (see page 16), Boucher's Fig. 4D discloses an exceptional case, 
where a fast path candidate, is sent to the slow path 44 (i.e., protocol stack) for 
processing. In other words, Boucher does not disclose that the fast path and the 
slow path are "different types of network traffic", since packets of the same protocol 
types (i.e., the TCP/IP or SPX/IPX) can be processed by both the fast path and the 
slow path. 

Accordingly, the Appellant maintains that Boucher does not anticipate 
Appellant's claim 1. Namely, Boucher does not disclose or suggest "processor 
operable to process a plurality of different types of network traffic, wherein each of 
said plurality of different types of network traffic corresponds to a different 
network protocol ," as recited in the Appellant's claim 1 . 

Il-C. Dependent Claims 3 and 19 

The Appellant stands by the arguments made in the corresponding section 
of the Brief on Appeal. The Examiner's Answer (page 19) states the argument as 
follows: 

"For claims 3 and 19, appellant has argued that prior art Boucher 
does not teach two or more of common Ethernet traffic, offload 
traffic, storage traffic, interprocess communication traffic (IPC) traffic, 
management traffic and RDMA traffic. 

It is respectfully submitted that Boucher does teach the limitation (col. 
10 lines 32-37, Ethernet traffic, col. 8 lines 3-12, col. 13 lines 42-67, 
SMB over TCP/IP or storage traffic directly forwarded to storage 
destination bypassing session, transport, network and datalink layer 



7 



Application No. 10/652,327 

Response to Examiner's Answer of June 22, 201 0 
Attorney Docket No. 13945US02 

processing, col. 7 lines 37-45, offload traffics such as TCP/IP, 
SPX/IPX)." 

Boucher discloses moving large messages via the fast path or slow path, 
such as file transfer to the final destination utilizing SMB (server message block) 
over TCP/IP, which is a type of offload traffic. For smaller messages, Boucher 
discloses packet messages sent under TCP/IP or SPX/IPX (i.e., the Netware 
version of TCP/IP protocol), which is an offload traffic. In other words, Boucher's 
SMB over TCP/IP and the TCP/IP or SPX/IPX protocols are different 
implementations of the offload traffic, which is a single common Ethernet traffic. In 
this regard, the Appellant maintains that Boucher still does not disclose or suggest 
" two or more of common Ethernet traffic, offload traffic, storage traffic, 
interprocess communication traffic (IPC) traffic, management traffic and RDMA 
traffic," as recited in Appellant's claims 3 and 19. Claims 3 and 19 are submitted to 
be allowable. 

Ill-A. Dependent Claims 10 and 11 

The Appellant stands by the arguments made in the corresponding section 
of the Brief on Appeal. The Examiner's Answer (pages 19-20) states the argument 
as follows: 

"For claims 10 and 11, appellant has argued that prior art Boucher 
and Kistler do not teach "server management functions". 

The examiner submits that the claims only recite "a server 
management agent" coupled to a keyboard or video or mouse 
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service, without reciting any management functions. Therefore, any 
keyboard or video or mouse service processing agent can be read as 
the claimed "server management agent," such as keyboard and 
mouse connected to an emulator that is coupled to a NIC (Kistler, 
fig. 3, [0026], emulator 324 has serial hardware interface, connecting 
to keyboard/video/mouse and NIC)." 

Appellant's claim 10 recites "a server management agent coupled to the 
processor". In other words, Appellant's "server management agent" has to be a physical 
hardware in order to be coupled to the "processor". However, the Examiner seems to 
equate Kistler's emulator 324, which is a software application (see Kistler at 1J0025) 
running within the operating system 322, to Appellant's "server management agent". In 
this regard, the Appellant maintains that Kistler does not disclose or suggest "a server 
management agent coupled to the processor," as recited in claim 10. 

Even though Kistler discloses that the keyboard/video/mouse connects to the 
emulator via a serial hardware interface, it does not change the fact that the emulator is 
still a software application, and the serial hardware interface is a mere physical connector, 
which enables the software codes be executed by the processor to be communicated to 
the keyboard/video/mouse. Therefore, the Appellant maintains that Kistler, likewise, does 
not disclose or suggest "the server management agent is coupled to a keyboard and/or 
video and/or mouse service," as recited in claim 11. Claims 10 and 11 are submitted to 
be allowable. 

IV-A. Dependent Claim 14 
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The Appellant stands by the arguments made in the corresponding section 
of the Brief on Appeal. The Examiner's Answer (page 20) states the argument as 
follows: 

"... appellant has argued that prior art Boucher and Microsoft do not 
teach "the unified driver is coupled to a software TCP processor and 
a socket service switch." 

The examiner submits appellant's mapping of the claimed subject 
matter is incorrect. From fig. 1, Microsoft clearly teaches a unified 
driver (NDIS driver) coupled to a software TCP processor 
(TCP/IP socket provider) and a socket service switch (Switch 
connected to socket application) similar to fig. 2 of the application 
(driver 450, software TCP/IP processor 460, switch 470 and services 
480)." 

The Examiner's above argument is still deficient. As shown in Microsoft's 
Fig. 1, Microsoft's NDIS driver (the alleged "unified driver") by-passes the TCP/IP 
sockets, a feature disclosed by Microsoft's SAN and WSD Architecture Model (see 
page 4). In this regard, Microsoft at least does not disclose or suggest "the 
unified driver is coupled to a software TCP processor and a socket service 
switch," as recited in Appellant's claim 14. 



IV-D. The Rejection of Claim 21 Using Official Notice 

The Appellant stands by the arguments made in the corresponding section 
of the Brief on Appeal. The Examiner's Answer (pages 20-21 ) states the argument 
as follows: 

"For claim 21, appellant has argued that prior art Boucher and what 
was known in the art (using Official Notice or ON) do not teach "time 
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division multiplexing (TDM) to determine which of the different types 
of network traffic access the software services via the single data 
path." 

The examiner respectfully disagrees. Boucher teaches assessing 
software services via a single data path (fig. 6, single data path 155 
processes traffics using fast-path processing and slow-path 
processing or at least two different traffics as shown in claim 1, 
traffics accessing source/destination or software services via path 
155). It was known in the art that TDM is a form of multiplexing in 
which transmission time is broken into segments, each of which 
carries one segment of one signal (Microsoft Computer 
Dictionary (fifth edition)). Therefore, it would have been obvious for 
one skilled in the art at the time of the invention to combine the 
teachings of Boucher and what is well known in the art to determine 
which of the different types of network traffic access the software 
services via the single data path as taught by Boucher by allotting 
multiple traffic segments of different types over one channel in 
different time slots using TDM as known in the art in order to 
minimize cost and complexity of building multiple channels or paths 
unnecessarily." 

In effect, the Examiner seems to equate "a signal" to "software services". 
The Appellant respectfully disagrees, and points out that "software services" refers 
to a specific application being performed over the time slot, while "a signal" is 
general without specificity. In this regard, the Examiner's Official Notice argument 
is still deficient without articulating factual or technical support. The Appellant 
maintains that the claimed TDM is for accessing software services via the single 
channel, and not for transfer of signals or bit streams, as alleged by the 
Examiner. Therefore, the Applicant maintains that TDM is not well known for 
" accessing software services via the single channel," as recited in Applicant's 
claim 21 . 
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V-A. The Rejection of Claim 22 

The Appellant stands by the arguments made in the corresponding section 
of the Brief on Appeal. The Examiner's Answer (pages 21 ) states the argument as 
follows: 

"For claim 22, appellant has argued that prior art Boucher and Yang 
do not teach "dynamically allocating fixed resources between among 
the different types of network traffic" because Yang's dynamic 
scheduling of data packets pertain to the physical L2 level only. 

This argument is vague as to what L2 level has to do with the 
claimed subject matter and there is no support for layer 2 in the 
argument. The rejection is maintained." 

The Examiner seems to have misconstrued Appellant's claim limitations in 
claim 22. Specifically, Appellant's claim 22 recites "dynamically allocating fixed 
resources among the different types of network traffic (i.e., accessing software 
services via the single data path)". In other words, the fixed resources refer to 
accessing which type of software services for the different network traffic types. 
Yang, however, (see Yang, [0015-0018]) refers the resources to bandwidth 
allocation, which is unrelated to Appellant's software services access allocation. 
Based on the foregoing rationale, the Appellant maintains that Yang is not a 
combinable reference with Boucher, and Appellant's claim 22 is submitted to be 
allowable. 

The Appellant reserves the right to argue additional reasons beyond those 
set forth above to support the allowability of claims 1-31 . 
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CONCLUSION 

For at least the foregoing reasons, the Appellant submits that claims 1-31 
are in condition of allowance. Reversal of the Examiner's rejection and issuance of 
a patent on the application are therefore requested. 

The Commissioner is hereby authorized to charge any additional fees or 
credit any overpayment to the deposit account of McAndrews, Held & Malloy, Ltd., 
Account No. 13-0017. 

A Notice of Allowability is courteously solicited. 

Respectfully submitted, 

Date: August 18, 2010 / Frankie W. Wong / 

Frankie W. Wong 
Registration No. 61,832 
Patent Agent for Appellant 

McAndrews, Held & Malloy, Ltd. 
500 West Madison Street, 34th Floor 
Chicago, Illinois 60661 
(312)775-8093 (FWW) 
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